home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group02b.txt / 000014_icon-group-sender_Mon Aug 19 12:51:49 2002.msg < prev    next >
Internet Message Format  |  2003-01-02  |  3KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7JJplQ13392
  4.     for icon-group-addresses; Mon, 19 Aug 2002 12:51:47 -0700 (MST)
  5. Message-Id: <200208191951.g7JJplQ13392@baskerville.CS.Arizona.EDU>
  6. From: Hrvoje Blazevic <hrvoje@despammed.com>
  7. X-Newsgroups: comp.lang.icon
  8. Subject: Re: What about "Expressions?" (was Re: Icon Wish List)
  9. Date: Sat, 17 Aug 2002 09:16:19 +0200
  10. X-Complaints-To: abuse@hinet.hr
  11. User-Agent: Pan/0.11.2 (Unix)
  12. X-Comment-To: "Gene Kahn" <jenjhiz@yahoo.com>
  13. To: icon-group@cs.arizona.edu
  14. Errors-To: icon-group-errors@cs.arizona.edu
  15. Status: RO
  16.  
  17. On Fri, 16 Aug 2002 17:38:22 +0200, Gene Kahn wrote:
  18.  
  19. >> Statements do not return values, they have side-effects, most notably
  20. >> assignment to variables that describe the state of the computation at
  21. >> any given moment.
  22. >> 
  23. > This is not without its advantage, of course. In particular, in terms of
  24. > readability, I find that explicit variables allow my mind to 'close'
  25. > (I'm not using it in the technical sense of "closure") previous
  26. > statements. On the other hand, in reading s-expression languages like
  27. > Lisp and Scheme, I find that I have to hold in my mind too many
  28. > _unstated_ intermediate results before I find what the expression is all
  29. > about. (One could argue that this may be due more to bad code, i.e.,
  30. > irresponsible use of deep embedding, than to intrinsic properties of
  31. > s-expressions). Compare the readability of these chunks of code:
  32. > 
  33. > FORTRAN-like
  34. > The man kicked the dog.
  35. > The dog chased the cat.
  36. > The cat bit the mouse.
  37. > The mouse died.
  38. > 
  39. > LISP-like (in infix notation)
  40. > The mouse the cat the dog the man kicked chased bit died.
  41.  
  42. Well -- this comparison is very unfair, a favorite imperative
  43. programmer's trick. I do not mean this in derogatory way. In the
  44. meantime I have checked your web-site, and have found a lot of
  45. interesting material, quite a lot of common interest.
  46.  
  47. In these two examples you are deliberately confusing programming
  48. languages, and human languages. Human languages are not formal
  49. systems, while programming languages are. When you force yourself
  50. (difficult in this example) to forget about standard meaning of
  51. English words, then the second example can make more sense than the
  52. first.
  53.  
  54. Phew -- I had to reach for GEB (Goedel Escher Bach) to answer this
  55. one.
  56.  
  57. But let's go back to programming paradigms;
  58.  
  59. Unfortunately, most programmers, and students would agree with you --
  60. following the state of variables is easier to understand, than holding
  61. a deep recursive structure in the head. I did have problems with this
  62. when I started with Logo and Scheme. However, given enough of
  63. endurance and several good books (and interestingly enough books from
  64. FP camp seem to be an order of magnitude better than those from
  65. imperative camp), one can stop trying to reason about processes that
  66. recursive procedures carry out in the terms of remembering values, and
  67. switch to the higher level of simply following the definitions of data
  68. structures that those processes work on.
  69.  
  70. When one is able to do this, imperative style all of the sudden starts
  71. looking complicated and mind limiting.
  72.  
  73. I will not bother you with very good arguments of when and where
  74. assignment is appropriate, and what are its advantages and
  75. drawbacks. (there are more drawbacks -- of course :-)
  76.  
  77. All this is very thoroughly described in HtDP and SICP.
  78.  
  79.